Modellierung und Verifikation medizinischer Leitlinien

نویسنده

  • Jonathan Schmitt
چکیده

time-annotationata ::= mk-ta( int-bottom, int-bottom, int-bottom, int-bottom, int, int-bottom, abstract-asbru-clock) | now ata Um mit abstrakten Zeit-Annotationen arbeiten zu können, werden einige Selektoren für die Komponenten der abstract-time-annotations definiert. Diese werden hier aufgeführt. Die Selektoren haben dabei selbsterklärende, jedoch abgekürzte Namen. Das Kürzel ” ess“ steht für den ” earliest starting shift“, also den frühesten relativen Startzeitpunkt. Dessen Gegenstück ist der ” lss“ (latest starting shift), der späteste relativen Startzeitpunkt. Analog dazu sind ” efs“ und ” lfs“ als frühste bzw. späteste relative Endzeitpunkte benannt. Die Abkürzungen ” minDu“ und ” maxDu“ stehen für die ” minimum duration“ und ” maximum duration“. Zuletzt steht der ” refPoint“ für den ” reference point“, der den Referenzzeitpunkt angibt. .ess : abstract-time-annotation 7→ int-bottom .lss : abstract-time-annotation 7→ int-bottom .efs : abstract-time-annotation 7→ int-bottom .lfs : abstract-time-annotation 7→ int-bottom .minDu : abstract-time-annotation 7→ int .maxDu : abstract-time-annotation 7→ int-bottom .refPoint : abstract-time-annotation 7→ abstract-asbru-clock Gegeben sei eine abstract-time-annotation ata mit ata = (bi1, bi2, bi3, bi4, i, bi5, aac). Die Semantik der oben aufgeführten Selektoren wird durch nachstehende Gleichungen definiert: ata.ess = bi1 ata.lss = bi2 ata.efs = bi3 ata.lfs = bi4 ata.minDu = i ata.maxDu = bi5 ata.refPoint = aac Abstrakte Zeit-Annotationen werden im Beispiel verwendet, um Planabhängigkeiten zu modellieren. Beispielsweise darf der Amoxicillin-Plan nur gestartet werden, wenn die Diagnose abgeschlossen wurde und feststeht, dass die Keime resistent gegen Penicillin sind. Auch darf der Antibiotika-Plan selbst nur gestartet werden, wenn Fieber für mindestens drei Tage nachgewiesen werden kann. Auch dies wird mittels abstrakter Zeit-Annotationen modelliert. 6.5 Unterplanlisten (plan-list) Die Planliste dient in Asbru dazu, die Menge und Reihenfolge der Unterpläne eines Planes zu beschreiben. Die Reihenfolge der Unterpläne ist beispielsweise für die sequential Kontrolle relevant, die diese auswertet. Andere Plankontrolltypen, wie etwa anyorder berücksichtigen die Reihenfolge nicht, sondern beachten nur die Menge der angegebenen Pläne. Die Planlisten sind bei wohlgeformten Asbru-Plänen duplikatfrei. Die in Abschnitt 9.2 und 9.3 angegebenen Regeln zur Ausführung von Asbru stellen die Semantik von Asbru-Planhierarchien nur dann korrekt dar, wenn die Unterplanlisten duplikatfrei sind.

برای دانلود رایگان متن کامل این مقاله و بیش از 32 میلیون مقاله دیگر ابتدا ثبت نام کنید

ثبت نام

اگر عضو سایت هستید لطفا وارد حساب کاربری خود شوید

منابع مشابه

Der Weg zur Modellbasierten Evolution und Adaption medizinischer Leitlinien

Ein medizinischer Behandlungsprozess setzt sich aus zumeist vereinheitlichten Abläufen und verschiedenen Entscheidungen zusammen. Um einen optimalen Behandlungsablauf für bestimmte Krankheitsbilder und Symptomkomplexe zu gewährleisten, werden klinikinterne Standard Operating Procedures, Verfahrensanweisungen oder übergeordnete Behandlungspfade festgelegt. Allerdings müssen diese Behandlungsanwe...

متن کامل

Integration von Model-Driven Development und formaler Verifikation in den Softwareentwicklungsprozess - eine Fallstudie mit einem 3D-Tracking-System

Bei modellgetriebener Softwareentwicklung werden Modelle entwickelt und aus diesen ausführbare Software generiert. Durch die Verknüpfung mit formaler Verifikation können Fehler in den Modellen gefunden und so der Ansatz der modellgetriebenen Softwareentwicklung verbessert werden. Diese Arbeit untersucht anhand von zwei Fallstudien, wie aktuelle Forschungsergebnisse im Bereich der Modellierung u...

متن کامل

Methoden und Beschreibungssprachen zur Modellierung und Verifikation von Schaltungen und Systemen

In modernen Prozessorentwicklungsprojekten kann die Verifikation von non-mainline Funktionen bis zu einem Drittel des Gesamtaufwandes für Verifikationstätigkeiten annehmen. Non-mainline Features beinhalten Initialisierungsund Resetsequenzen, Zuverlässigkeits-, Zugriffsund Debugschnittstellen, Sensoren, Bist-Mechanismen oder auch Debugund Trace-Funktionen. Im Gegensatz zur bereits stark fortschr...

متن کامل

ذخیره در منابع من


  با ذخیره ی این منبع در منابع من، دسترسی به آن را برای استفاده های بعدی آسان تر کنید

عنوان ژورنال:

دوره   شماره 

صفحات  -

تاریخ انتشار 2008